Las fuentes de los requisitos
Introducción
Las fuentes de los requisitos son los elementos fundamentales que originan los objetivos y necesidades que debemos estudiar, comprender y analizar para obtener una recopilación de requisitos que satisfaga el sistema desarrollado.
Existen tres grandes fuentes de requisitos:
Stakeholders: Cualquier persona, grupo u organización que está involucrada en el proyecto, resulta afectada, o puede influir en el resultado.
Documentos: Pueden contener información relevante para la especificación del producto.
Otros sistemas.
Los Stakeholders
Podemos distinguir entre dos tipos de Stakeholders:
Cliente: es la organización o individuo que ha solicitado la contrucción del producto y lo recibirá.
Los usuarios son un tipo importante de cliente, pues serán quienes utilicen finalmente el producto.
Los usuarios directos trabajarán directamente con el producto, interactuando con él.
Los usuarios indirectos se beneficiarán indirectamente del producto, consumiendo otros productos generados a partir del sistema o utilizándolo a traves de otras aplicaciones.
Otras partes interesadas: no son clientes directos pero pueden ser afectados por el producto, por el proceso de desarrollo o utilización , o proporcionan servicios durante el ciclo de vida del producto.
No todos los stakeholders son usuarios ni todos los clientes son usuarios.
Clasificación de los usuarios
Podemos clasificar a los usuarios en varias clases:
Clases de usuario favorecidas: son a los que les ofrecemos funcionalidades que les aportan valor.
Clases de usuario desfavorecidas: son los usuarios a los que quiero impedir el uso de la aplicación (Hackers, piratas...)
Clases de usuario ignoradas: Son usuarios irrelevantes y suelen ser pocos.
Otras clases de usuario: son los que no podemos clasificar en ninguna de las clases anteriores.
Información suministrada por clientes y usuarios
Requisitos de negocio:
Son necesidades que originan el nuevo producto o modificación.
Proporcionan un marco de referencia para el desarrollo.
Definen el valor que aporta el producto.
Descomponen la visión general en metas concretas.
Ejemplo: Aumentar la cuota de mercado en la región X en un Y% en los próximos Z meses.
Requisitos del usuario
Son objetivos de clases de usuario concretas.
Actividades relacionadas con los requisitos.
Se documentan como escenarios, casos de uso o historias de usuario.
Ejemplo: Como responsable de ventas necesito disponer de un histórico de los contratos firmados para poder analizar la cuota de mercado.
Reglas de negocio
Indican normas y restricciones impuestas por el entorno.
No son requisitos funcionales, pero suelen originarlos.
Ejemplo: En la región X se paga un impuesto de sociedades del N%.
Atributos de calidad
Son características que determinan la calidad que percibe el usuario.
Suelen expresarse de manera ambigua, y están relacionados con características de rapidez, facilidad, usabilidad...
Ejemplo: La aplicación móvil debe abrirse rápido y no hacerme esperar mucho.
Ideas de solución
Muchas veces los usuarios expresan como requisitos soluciones de implementación.
El analista deberá descubrir el requisito que esta detrás de esta necesidad, preguntándole ¿Por qué?
Ejemplo:
Usuario: Quiero seleccionar la dirección de envío desde una lista desplegable.
Analista: ¿Por qué una lista desplegable?
Documento de visión y alcance
El documento de visión y alcance define la visión de la solución y el alcance del producto.
La visión de producto describe de manera breve el tipo de producto capaz de satisfacer los objetivos de negocio. Es una imagen a futuro que refleja aspiraciones y expectativas de clientes y usuarios, y un estado que se desea alcanzar.
El alcance del proyecto identifica qué parte de la visión se espera alcanzar en un proyecto o la iteración. En definitiva, delimita qué aspectos quedan dentro y cuáles fuera del desarrollo.
Requisitos de negocio: descripción general de la necesidad y su solución.
1.1. Antecedentes: razón que lleva al desarrollo de un producto nuevo (punto de partida).
1.2. Oportunidad de negocio: se trata de justificar los beneficios que supone el nuevo desarrollo (necesidad identificada).
1.3. Objetivos de negocio: los beneficios qué queremos conseguir (económicos y no económicos).
1.4. Métricas de éxito: definir métricas que ayuden a evaluar los resultados.
1.5. Visión general: resumir el propósito del producto.
1.6. Riesgos de negocio: identificar las posibles amenazas al desarrollo del producto (productos competidores, problemas de tiempos, dificultades en la aceptación del usuario...). Están más relacionados con aspectos tecnológicos y con los recursos.
1.7. Suposiciones y dependencias: Identificar qué suposiciones asumimos como ciertas o estables.
Alcance y limitaciones: el alcance describe el contenido del proyecto y las limitaciones enumeran características que no incluirá el producto.
2.1. Principales características: resaltar las principales características del producto.
2.2. Alcance de la primera release: características incluidas en la primera release.
2.3. Alcance de las siguientes releases: características qué dejamos para futuras versiones.
2.4. Limitaciones y exclusiones: Expectativas de los usuarios que no están incluidas en el alcance).
Contexto de negocio: es el punto de partida para el analista.
3.1. Perfiles de los stakeholders: establecer una clasificación de los stakeholders.
3.2. Prioridades del proyecto: características prioritarias para los stakeholders (no negociables).
3.3. Consideraciones para el despliegue: indicar cualquier información recopilada durante el proceso que pueda ser de utilidad para el despliegue del producto.